ProNET is a simple network system. The most important use is to share devices like hard disks, floppies and CD-ROM drives between computers in the network.
I call it simple because it is not, will never be and is not ought to be a real competitor to existing standards like TCP/IP. I'm not a networking specialist; I didn't study a single book on this subject, so one can't expect ProNET to be an absolutely professional product.
The ProNET software is based on two-sided connections, which means that you can not connect more than two computers on one interface level - each level has always got two ends. This is called the Client-Server-Model:
/--------\ /--------\ | | ---- REQUEST --->> | | | Client | | Server | | | <<-- RESPONSE ---- | | \--------/ \--------/
But since ProNET uses a modular driver concept, you can open up more than one connection from each computer, so that you could hook together more than two of them.
Besides that, ProNET is limited to the Amiga series of computers. There will never be ports to other platforms, because the File System heavily relies on the Amiga way of handling data storage media.
Considering these facts, ProNET is the right program package for you, if you
This description might call the ParNet package into your mind, and indeed ProNET is ought to be the follow-up to that nice, but quite old and restricted software. These are some examples of improvements to Matt Dillon's work:
Please do also note that there is no installation script -- if you want to use ProNET, you should be familiar with the Shell and Text Editors.
The software generally requires at least Kickstart 2.0 and runs on any processor, with some exceptions: `pronet-server', `pronet.device', `pronet-talk' and the interface drivers do also work on older versions. Only Kickstart 1.3 has been tested, though.
Before we start moving around files, just let me explain what Devices are. If you find yourself familiar with these things you can skip this section and start installing. If you don't quite understand the install procedure, this section might enlighten you!
Because AmigaDOS can handle more than one data storage medium, each one has got its own name. The most known examples are `DF0:' for the internal floppy disk drive and `HD0:' for the boot partition of your hard disk. Every time you access a file on one of these media, you will state this name, provided the disk is not already the root of the current directory.
All these names describe a thing in AmigaDOS which is called the AmigaDOS Device. `CD0:', `HD7:', `PRT:' and `RAM:' all describe different AmigaDOS Devices, also simply called Devices. As you have probably noticed about the example of `RAM:', the AmigaDOS Device is only a symbol for a storage medium, since the Ram Disk is not really part of the hardware!
This device is not to be confused with the Exec Device, though both are just called Device in general. The former is a symbol, the latter is a program located in the ROM or in the `DEVS:' directory, the name of which is usually ending with `.device'. Exec devices are low-level drivers for hardware like hard disk drives and floppies. In this case, you don't need to know how they work or what they are good for.
The pronet.device is the core of the whole ProNET package. It
contains all routines for managing the data transfer between Amigas. It
does not contain any transfer routines as was the case in version 1,
because it turned out to be extremely hard to add new routines for other
interfaces this way.
The device should be copied into the `DEVS:' directory of all participating machines.
The transfer routines are external code modules stored in the `DEVS:ProNET' directory. I would recommend copying all of them, though you can lateron delete the unused ones. Please don't copy them directly into `DEVS:', but keep them in their own directory!
As soon as you receive your key file, copy it as `.key' to the same directory `DEVS:ProNET/'.
Currently available transfer modules are `internal-parallel' for the
internal parallel port (which, by the way, was the only possibility in
ProNET V1), `mfc-parallel' for the parallel port of a
MultiFaceCard3, and `serial' for serial ports which are controlled
through a serial.device compatible
Exec Device, that is
`BaudBandit.device', `duart.device' etc.
Now create the file `DEVS:ProNET/.config'. This file will contain configuration data for the ports you are using for the network.
This file contains any number of lines of the following form:
[drivername] [driverdata]
Each line describes a so called Unit of the device, representing a port accessable by one of the ProNET drivers. The more ports and drivers you have, the more Units you can create. You will be able to use every unit to connect to another machine: If your central Amiga contained a Multiport expansion containing 3 serial ports, you would be able to connect to 5 (five!) other Amigas by using the internal parallel and serial ports, as well as the Multiport card.
Units are numbered from 0 to n. Unit 0 is defined by the first line in `.config', Unit 1 by the second line and so on. [drivername] is replaced by the name of the external driver module, and [driverdata] is configuration data required by this driver.
First we will install the internal-parallel driver. If you don't need it, skip this part. We add the line:
internal-parallel 0 5
The number 5 is required by the driver module and describes the priority of the transfer process. If you don't know what I'm talking about, leave this number. Lower numbers, like 0, can prevent the driver from stealing most of the CPU time.
The number 0 is the so called machine number and is essential for the correct working of the network. Two machines connected via the internal- or mfc-parallel driver need to have different numbers here. One machine requires a `0', the other one a `1'. If you gave both sides the same number, ProNET might not work.
This driver works with a ParNet compatible cable at the built-in parallel port.
This driver can be useful if you've got the MultiFaceCard3 from BSC. The on-board serial ports should be driven with the serial driver described below, the parallel ports are used with this driver.
Please note that you can only use MultiFaceCards which contain the 6821 PIA from Motorola -- it has only been tested with the MultiFaceCard3.
Let's get down to the installation and create a new line:
mfc-parallel 0 1 5
0 is the number of the MFC parallel port, in case you've got more than one card in your Amiga.
The number 1 is the so called machine number and is essential for the correct working of the network. Two machines connected via the mfc- or internal-parallel driver need to have different numbers here. One machine requires a `0', the other one a `1'. If you give both sides the same number, you run the risk of some dangerous network deadlocks (no, you don't destroy your hardware)!
The number 5 is required by the driver module and describes the priority of the transfer process. If you don't know what I'm talking about, leave this number. Lower numbers, like 0, can prevent the driver from stealing most of the CPU time.
This driver works with a ParNet compatible cable. It is, without problems, possible to connect two Amigas with a MFC at one side and a built-in parallel port on the other side. This won't give you the optimum in performance, though.
If you want to use it, create the line:
serial BaudBandit.device 0 19200
BaudBandit.device is the name of the serial.device you want to
use, 0 is the appropriate unit, which would describe the number of the
serial port on
multiport cards. Please note, that 8n1.device does not function on
an A500 with this driver. If you want to be really sure, use the original
serial.device here.
19200 is the baud rate, which must be equal on two computers connected together. Try how high you can set it! 19200 is a very safe value which even works on unaccelerated A500 models. Typical higher settings are 38400, 57600, 64000, 76800, 115200. The result of selecting a too high value is that the network could suddenly stop working, especially when the CPU working hard. The system could even work okay for half an hour and then stop working.
Without further arguments, this driver requires a 7-wire null-modem cable to work. However, the time could come when you only have 3 wires (e.g. when networking with a CD32). In this case, add the argument 3WIRE to the end of the line (on both sides of the cable, of course). Note that 3-wire connections are generally less stable than 7-wire ones, especially under heavy multitasking.
Please note that, when using this driver, the server always has to be started first, after that you can mount the devices on the other machine. This is because the driver can't wait for the other machine to be alive, as opposed to the parallel drivers.
Please note that whatever you do, you'll do it on your own risk! I can't be held responsible for any damages you might do to your hardware.
The following description is based on the ParNet documentation.
You are making a cable that connects the two parallel ports of your Amigas together. Connect D7-D0, SEL, POUT, and BUSY across; connect ACK to SEL locally:
(2-9) D7-D0 ------------ D7-D0 (12) POUT ------------ POUT (11) BUSY ------------ BUSY PARALLEL PORT (13) SEL --+------+-- SEL (10) ACK -/ \- ACK (18-22) GND ------------ GND (18-22)
This is the DB-25 parallel connector seen from outside the computer:
1 13 _______________________________ \ . . . . . . . . . . . . . / \ . . . . . . . . . . . . / --------------------------- 14 25
Attention A1000 users: The parallel port is male, so you need a female connector! Other Amigas need a male connector.
The easiest thing to do is to buy a premade cable with all 25 lines passed and DB25 connectors on both ends (Double check the gender's that they match before you buy the cable!) And then rip it apart and cut-and-seal those wires which are not supposed to be connected. You also need to bridge ACK to SEL as per the diagram above on both ends of the cable, as shown above.
Double check the gender for the DB25 connectors you will need to connect to your Parallel Port. Never plug in an unmodified cable between the two computers! Double check your cable before installation!
The longer you make the cable, the more unstable the network will get. But not only that, you can destroy your CIA chips when using too long cables. 5m is perfectly safe, and I heard from people using 10m cables without problems, but I wouldn't want to go beyond five.
Warning: The RI (Ring Indicate) line on the Amiga's built-in serial port (Pin 22) uses the SEL line to source a transitor. This interferes with the SEL line which, as you can see, is part of the network.
Be sure that
Otherwise, when receiving a signal on the RI line, the
internal-parallel driver would simply crash!
Note that you must try to keep the cable as short as possible. You don't destroy hardware otherwise, but the network might be very unstable. 5m is safe, however.
Two ports should be connected in this way to give a 7-wire null-modem cable:
Shield Earth -> Shield Earth
System Earth -> System Earth
TXD -> RXD
RXD -> TXD
RTS -> CTS
CTS -> RTS
DSR -> DTR
DTR -> DSR
Do not connect Shield and System earth.
To get a 3-wire cable, leave out the DSR/DTR and RTS/CTS connections, so that we use the following schematics:
Shield Earth -> Shield Earth
System Earth -> System Earth
TXD -> RXD
RXD -> TXD
Do not connect Shield and System earth here either.
If you've got standard serial ports, please think about using 7-wire cables, as they are more reliable.
...are the standard Amiga ports.
Shield Earth (GND) - Pin 1
System Earth (GND) - Pin 7
TXD - Pin 2
RXD - Pin 3
RTS - Pin 4
CTS - Pin 5
DSR - Pin 6
DTR - Pin 20
This is the DB-25 RS-232 connector seen from outside the computer:
1 13 _______________________________ \ . . . . . . . . . . . . . / \ . . . . . . . . . . . . / --------------------------- 14 25
...are mostly used in the rest of the computer world and sometimes can even be found on Amiga multi-I/O cards such as the MultiFaceCard3.
Shield Earth (GND) - (connect to frame)
System Earth (GND) - Pin 5
TXD - Pin 3
RXD - Pin 2
RTS - Pin 7
CTS - Pin 8
DSR - Pin 6
DTR - Pin 4
This is the DB-9 RS-232 connector seen from outside the computer:
1 5 _______________ \ . . . . . / \ . . . . / ----------- 6 9
This is easy: Let's assume your main working place is an A4000. You want to import the CD-ROM drive of a CDTV that is placed under your table into the A4000 so that you don't need to spend money on a new SCSI CD-ROM drive for your workstation. In this configuration it's quite obvious that the CDTV will be the network Server, whereas the A4000 will be the Client.
Just copy `pronet-server' into the `C:' directory or somewhere else in the path of the Server, that is the machine from which you want to import AmigaDOS Devices into the main machine. Then put the `pronet-handler' into the `L:' directory of the main machine, the Client.
That's it!
Copy `pronet-run', `pronet-page', `pronet-start', `pronet-stop' and `pronet-talk' into the `C:' directory of your machines. That's it, again!
If you are currently using ProNET V3 and want to update, you don't need to start from the beginning: Here I will show you how to change your installation.
A detailed list of the changes can be found in the accompanying file `ChangeLog'.
For any Amiga you want to use as a server, you first have to start `pronet-server'. By default, this program waits for incoming request on ProNET Unit 0, but you can change this by supplying another value in the command line, so, if you had several connections to a central server computer, you would have to start `pronet-server' once for every Unit.
If you forget to start the server, client programs will simply go into an endless loop, so when later on nothing seems to work, always check if the server is running!
The server can be stopped at any time by issueing a `CTRL-C' signal.
I would do so before rebooting the Client machine, since the server will
then give notice of its departure.
I suggest starting the server with run <>nil: so it doesn't block
your shell. If you want to stop it, use the `status' and `break'
commands.
Starting the network is a very simple job, which is done by the `pronet-start' utility.
The command template is as follows:
pronet-start LOCALNAME/A,REMOTENAME/A,UNIT/N,FLAGS/N,UNIQUE/S
LOCALNAME is the name of the Device to create while REMOTENAME is the one you want to import from a remote Amiga. It is important not to give a volume name (e.g. `Work') here but the device name (such as `hd0')! Please also note that you must not append a `:' to the Device names!
As for the example from above, we could issue the command
pronet-start cd1 cd0
^^^
This is what we want to
call the device on the A4000.
^^^
This is what the device is
called on the CDTV.
The rest of the arguments don't necessarily have to be specified:
UNIT is the ProNET unit you want to use (default 0). FLAGS currently has no effect (defaults to 0, too) and the UNIQUE switch makes Volume names unique. Imagine the following configuration:
Two Amigas with both a `Workbench' partition are connected and Amiga 1 wants to access the Workbench partition of Amiga 2. You call `pronet-start' and what happens? Now you have got two `Workbench' volume icons on your screen. This will confuse AmigaDOS quite heavily, which is to be avoided by using the UNIQUE switch. This will simply append a number to the imported volume name, corresponding to the ProNET unit you have used.
`pronet-start' returns an error message if something went wrong, that is e.g. when the remote device doesn't exist or the ProNET unit can't be found. Otherwise it immediately returns without further output. Don't start it with `run', the command immediately returns!
Now repeat this step for every new device. Good luck!
When you feel that you don't need a remote device any more, you can remove it with this command. Supply `pronet-stop' with the device name you want to remove and it will do its job. You could also give the UNIT keyword together with a Unit number. `pronet-stop' will then stop all devices on this specific Unit.
Why should you do this? Well, if you switched off the Server or reset it without stopping the Client, strange things might happen on the Client: You couldn't access any data any more, perhaps you couldn't even move your mouse -- this is because the Client thinks the Server's still alive!
Beyond question: If you're going to switch off both computers anyway, you can skip this of course.
You can use this command without further arguments to remove `pronet.device' from memory. This will free all resources allocated by the ProNET drivers. `pronet-server' and `pronet-stop' have this feature built-in. You will hardly find appropriate use for this command, but it's there for reasons of completeness anyway.
Using this program, you can send messages to users on remote machines. This works by calling `pronet-page' with the ProNET Unit and the message to be displayed on the machine connected to that Unit.
Example:
pronet-page 0 Hello there!
The message will be displayed in a Guru-like alert window at the top of the screen.
By using this program, you can run programs on a networked machine without
having to touch its keyboard or mouse. Call it with the ProNET Unit
and the command to be run on the corresponding Amiga. The command string
must be put in "s.
Example:
pronet-run 0 "dir hd0: all" pronet-run 13 "list >con:0/0/640/200/test"
It is important to know that the standard output is done into the window that the respective pronet-server was started from. Therefore I strongly advise you to explicitly redirect standard output, like I did in the second example.
This program can be used to chat between two machines. All you need to do is call `pronet-talk' on both machines with the right ProNET Unit as an argument. By default, this program uses Unit 0.
In this chapter, I want to give you some hints to how to use the full power of ProNET. There are some things which are not very obvious and may be useful for some of you.
Okay, this is not quite what I would call advanced usage, but it's the right place for this anyway.
Let's get back to the example from the Importing Devices section. You will sometimes have to reboot your A4000, because some program has crashed (uuh not really, we use an Amiga ;-)). When you want to start the network again, you don't have to reboot the CDTV, too -- It's completely okay to issue new `pronet-start' commands after a Client reboot without rebooting the Server. That's all.
Most configurations will look similar to the one described above, i.e. one main machine, the working place, and a server which is no working place. However, if you are networking with a friend's system and you are both working on the machines, it's no problem to install the network in both directions, that is both machines are Server and Client at the same time. The two can each access the other one's file systems.
Imagine you have a friend living far away from you, and you want to help him install some new programs. You could call him and describe exactly what he has to do, but this way you will spend far too much time, because he will not understand (This presumption has been derived from Murphy's Law and proved to be fact in many situations ;-)).
You could also make a modem connection, install a network between your computers and copy all the files to the right places, make some shell scripts etc. on your own. Does this sound interesting? Then read on!
Both sides must define a ProNET Unit using the `serial' driver. The respective port will not have a null-modem cable connected to it, but a real modem! As usual, set the serial port speed to four times the modem speed, if your port does it. The speed settings on both sides don't have to be equal, because the modem manages the transfer speed on its own.
Both modems must be configured to ignore the DTR (data terminal ready) signal,
which is in most cases done by issueing the command AT&D0.
Load your favourite terminal programs now. Decide one of you to be the
caller, who then dials the other one's number via ATD. As soon as
he has answered with ATA and you've read the CONNECT message,
both sides quit the terminal.
Now simply proceed as if you were connected with a simple null-modem cable: Start the server programs and install the devices (of course directed to the right unit!). That's it. Not very fast, but nice anyway ;-)
Read the two autodoc files that are in the distribution. There is one for general `pronet.device' usage and one for developing new ProNET drivers.
ProNET supports most of the new DosPackets introduced with V36 and V39: Perhaps you've sometimes seen one of these '2.0 Pkt ACT_PARENT_FH' requesters from ParNet - they are no longer annoying you! This is a list of all packet types supported by ProNET:
ACTION_FINDINPUT ACTION_FINDUPDATE V33 ACTION_FINDOUTPUT ACTION_END ACTION_READ ACTION_WRITE ACTION_SEEK ACTION_CURRENT_VOLUME ACTION_SET_FILE_SIZE V36 ACTION_LOCK_RECORD V36 ACTION_FREE_RECORD V36 ACTION_LOCATE_OBJECT ACTION_FREE_LOCK ACTION_COPY_DIR ACTION_PARENT ACTION_SAME_LOCK V36 ACTION_CREATE_DIR ACTION_CHANGE_MODE V36 ACTION_FH_FROM_LOCK V36 ACTION_COPY_DIR_FH V36 ACTION_PARENT_FH V36 ACTION_EXAMINE_OBJECT ACTION_EXAMINE_NEXT ACTION_EXAMINE_FH V36 ACTION_DELETE_OBJECT ACTION_RENAME_OBJECT ACTION_MAKE_LINK V36 ACTION_READ_LINK V36 ACTION_SET_COMMENT ACTION_SET_DATE ACTION_SET_PROTECT ACTION_INFO ACTION_RENAME_DISK ACTION_INHIBIT ACTION_FORMAT V36 ACTION_SERIALIZE_DISK V39 ACTION_MORE_CACHE ACTION_WRITE_PROTECT ACTION_IS_FILESYSTEM V36 ACTION_NIL ACTION_FLUSH ACTION_DISK_INFO
These packets are not yet supported and might be implemented later:
ACTION_EXAMINE_ALL V36 ACTION_EXAMINE_ALL_END V39 ACTION_SET_OWNER V39 ACTION_ADD_NOTIFY V36 ACTION_REMOVE_NOTIFY V36
Due to the costs of ordinary mail, it's generally not possible for me to answer every question concerning ProNET by snail-mail. If you've got an Internet address, the chance of an answer will rapidly increase. Also please do try to find a solution to your problem in the FAQ section of this guide first.
ProNET development has stopped with Version 3.2. The only case in which I could imagine releasing a V3.5 would be when someone reports a really bad bug (not a missing feature). I haven't got a single bug report within the last two years, so I assume this program is quite stable by now.
Here is a list of addresses you can use to contact me:
Michael Krause Mannesallee 24 D-21107 Hamburg Germany m.krause@tu-harburg.de rawstyle@ms.demo.org michael@tnx.de http://www.tu-harburg.de/~semk2104/
If, somewhen in the future, all these addresses should fail to work, you can easily start a search in the WWW (or whatever medium is "in" at that time) for my name in conjunction with "ProNET". You'll definitely find me this way.
All ProNET software by
Michael Krause
ParNet (inspiration) and design of the parallel connection cable by
Matt Dillon and the Software Distillery
People who helped me with testing the software and giving valuable hints to bugs I would have never discovered (THANKS!):
Thomas Schwarz, Wolfgang Gutberlet, Mat Bettinson, Robert W. Adams, Nik Soggia, Anti-"It-does-not-work"-brain
Besides all that I also want to thank all people that sent letters containing more than just `ProNET does not work' and all the ones encouraging me to continue working on this package. This update would never have been released if I hadn't received so much mail from you!
This section only lists the most important changes. A more profound text can be found in the `ChangeLog' file.
released on 29-May-1999. No actual code changes, but removed the Shareware requesters and added the complete source code to the distribution.
released on 17-May-98. No actual code changes, only the documentation has been fixed in some places (addresses).
released on 27-Jan-97 including pronet.device 38.0, pronet-handler 38.0, pronet-server 38.0, pronet-start 37.0, pronet-stop 38.0, pronet-flush 36.0, pronet-talk 37.1, pronet-run 37.0, pronet-page 37.0, internal-parallel 37.0, mfc-parallel 37.0, serial 37.0.
released on 30-Nov-96 including pronet.device 37.2, pronet-handler 37.1, pronet-server 37.0, pronet-start 37.0, pronet-stop 36.1, pronet-flush 36.0, pronet-talk 37.1, pronet-run 37.0, pronet-page 37.0, internal-parallel 37.0, mfc-parallel 37.0, serial 37.0.
released on 23-Aug-96 including pronet.device 36.6, pronet-handler 36.4, pronet-server 36.4, pronet-start 36.3, pronet-stop 36.1, pronet-flush 36.0, pronet-talk 36.0, pronet-run 36.1, pronet-page 36.0, internal-parallel 36.1, mfc-parallel 36.0, serial 36.2.
(bugfix) released on 08-Jul-95 including pronet-talk 34.2, pronet-server 35.0.
released on 24-Jun-95 including pronet.device 35.4, pronet-handler 34.2, pronet-server 34.9, pronet-talk 34.1, pronet-run 34.1, pronet-page 34.0.
released on 01-Nov-94 (initial release) including pronet.device 33.9, pronet-handler 33.5, pronet-server 33.5, pronet-talk 33.0, pronet-run 33.0, pronet-page 33.0.
I got the idea for ProNET in December 1993 after being disappointed by ParNet and started programming the device in April 1994.
diskchange cd0:
command on the client or server machine.
Hmm... sorry that there were not too much questions I could answer with a simple `Yes' :) ohh well but let me think about that again... ahhh here it is:
This program is released under the terms of the GNU General Public License; see the file COPYING in this distribution.
This document was generated on 29 May 1999 using the texi2html translator version 1.51.